home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93b.txt / 000020_icon-group-sender _Sun Apr 25 00:41:30 1993.msg < prev    next >
Internet Message Format  |  1993-06-16  |  5KB
  1. Received: by cheltenham.cs.arizona.edu; Sun, 25 Apr 1993 18:22:55 MST
  2. Date: 25 Apr 93 00:41:30 GMT
  3. From: agate!howland.reston.ans.net!usc!cs.utexas.edu!news.uta.edu!utafll.uta.edu!bruce@ucbvax.Berkeley.EDU  (Bruce Samuelson)
  4. Organization: UTexas at Arlington, Linguistics
  5. Subject: Lack of robustness limits Icon's popularity
  6. Message-Id: <BRUCE.93Apr24184130@utafll.utafll.uta.edu>
  7. References: <9304230936.AA23022@univ-caen.fr>
  8. Sender: icon-group-request@cs.arizona.edu
  9. To: icon-group@cs.arizona.edu
  10. Status: R
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12.  
  13. Another possible reason Icon is not more popular is lack of
  14. robustness in some circumstances.
  15.  
  16. A friend who programs in C needed to write some software to index and
  17. compress several megabytes of text data for use in a commercial
  18. product. Each multimegabyte text is indexed and compressed once and
  19. placed on floppy disks. I suggested Icon as the ideal language.
  20.  
  21. Although he had never used it before, he followed my suggestion.  He
  22. was impressed by how effective it was at implementing his parsing and
  23. compression algorithms, but he was plagued by its unreliability.
  24.  
  25. Compression runs would take several hours on his 486/33 with 8MB of
  26. memory running DOS 5.0. That wasn't a particular problem, since he ran
  27. it overnight. The real problem was that when he checked the results
  28. the next morning, he could never be sure whether the run would
  29. complete or crash. His and my best guess was that he was bumping up
  30. against some memory constraint.
  31.  
  32. He did try adjusting the various parameters you can set when compiling
  33. Icon. I think string space was one he modified to be able to process
  34. larger texts. However, he was never able to find settings which would
  35. guarantee consistently reliable runs. He insisted the program was so
  36. fragile that even the presence or absence of a comment in the soure
  37. code could determine whether it would crash. I don't remember the Icon
  38. version number, other than that when I ftp-ed it a year or so ago it
  39. was the most current one for 32-bit Intel--8.something I think. It was
  40. interpreted, not compled.
  41.  
  42. I told him that my experience with Icon on a Sun workstation running
  43. Unix had been more positive, and that I only encountered one serious
  44. bug for which there was a workaround. (With DOS, using an older
  45. version of Icon that was restricted to 640K, my experiences were even
  46. worse than my friend's, but that was to be exptected.) My positive Sun
  47. experience failed to console him.
  48.  
  49. In the end, he did manage to get all the texts compressed, writing C
  50. modules in place of Icon ones when necessary. The company had
  51. considered turning their compression software into a commercial
  52. product. It started out being written for internal use only. My friend
  53. is a good programmer and documents his systems well. Unfortunately,
  54. his Icon programs are too fragile to sell commercially. Another
  55. problem, of course, is the niche nature of the language. Source code
  56. written in C would seem to offer more commercial potential.
  57.  
  58. In a postmortem analysis, my friend said that if he could do it all
  59. over again, he would have simply used C.
  60.  
  61. He does not have internet or usenet access. I tried to get him to find
  62. a benefactor at the local university who could give him an account,
  63. but he didn't pursue this vigorously. I told him that if he had posted
  64. his symptoms in detail to this newsgroup, and perhaps reported them to
  65. the Icon project, he might have gotten some practical help.
  66.  
  67. It is not fair for me to complain about Icon's robustness to this
  68. group without giving sufficient documentation so that one of you could
  69. track down the problem and fix it. It could be as trivial as a
  70. compiler flag or setting. And perhaps the 32-bit DOS version of Icon
  71. is one of the poorer ones. I have no idea. But I think this does
  72. illustrate that for at least one version of Icon, intermittant,
  73. unreproduceable runtime failures in building indexes for and
  74. compressed representations of fairly large texts limits its
  75. popularity. There were so many ways my friend caused intermittant
  76. crashes by legitimately modifying his source code that he will
  77. probably never again use Icon again for serious work. On a more
  78. positive note, I would, under the right circumstances.
  79. --
  80. **********************************************************
  81. * Bruce Samuelson    Department of Linguistics     *
  82. * bruce@ling.uta.edu    University of Texas at Arlington *
  83. **********************************************************
  84.